Host controller interface for universal serial bus (usb) power delivery

ABSTRACT

An apparatus, comprising a system management bus configured to communicate with a USB PDC, and a processor coupled to the system management bus and configured to send a power delivery configuration to the PDC, wherein the power delivery configuration comprises voltage and current settings, and receive a power delivery status from the PDC. Also disclosed is an apparatus comprising a power bus interface configured to communicate with a USB port partner, a system management bus interface configured to communicate with a host, and a processor coupled to the power bus interface and the system management bus interface, wherein the processor is configured to receive, via the system management bus interface, a power delivery configuration from the host, generate a power capability message based on the power delivery configuration, and send, via the power bus interface, the power capability message to the USB port partner.

CROSS-REFERENCE TO RELATED APPLICATION

The present application claims priority to U.S. Provisional PatentApplication 61/754,846, filed on Jan. 21, 2013 by Deric Waters, et. al.,and entitled “Host controller Interface For USB Power Delivery”, whichis incorporated herein by reference as if reproduced in its entirety.

BACKGROUND

Universal Serial Bus (USB) may have evolved from a data interfacecapable of supplying limited power to a primary provider of power with adata interface. Today some devices may be charged and/or powered via USBports contained in laptops, cars, aircraft and/or wall sockets. The USBPower Delivery (PD) specification version 1.0, which is incorporatedherein by reference as if reproduced in its entirety, is defined toenable more flexible power delivery and provide higher power over USB PDcables and connectors. For example, the USB PD specification mayincrease power levels up to about 100 Watts (W), allow a power consumerand/or a power provider to swap roles, optimize power management acrossmultiple peripherals, and/or manage power at a system level. The USB PDspecification defines a communication link and protocol between USBports connected via a USB PD cable and connectors, where a pair of USBPD port partners (e.g. a provider port and a consumer port) may exchangepower delivery capabilities and negotiate power requirements over thecommunication link.

SUMMARY

A host interface for USB PD is disclosed herein. In one embodiment, anapparatus includes a system management bus and a processor. The systemmanagement bus is configured to communicate with a USB Power DeliveryController (PDC). The processor is coupled to the system management busand configured to communicate with the PDC via the system managementbus. The process is further configured to send a power deliveryconfiguration to the PDC, wherein the power delivery configurationcomprises voltage and current settings, send a power delivery command tothe PDC, wherein the power delivery command instructs the PDC to requesta power capability of a USB port partner, and receive a power deliverystatus from the PDC, wherein the power delivery status comprises thepower capability of the USB port partner.

In another embodiment, an apparatus includes a power bus interface, asystem management bus interface, and a processor. The power bus isconfigured to communicate with a USB port partner. The system managementbus interface is configured to communicate with a host. The processor iscoupled to the power bus interface and the system management interface.The processor is further configured to receive, via the systemmanagement bus interface, a power delivery configuration from the host,wherein the power delivery configuration comprises voltage and currentsettings, generate a power capability message based on the powerdelivery configuration, send, via the power bus interface, the powercapability message to the USB port partner, and send, via the systemmanagement bus interface, a power delivery status to the host, whereinthe power delivery status comprises a USB plug detection status.

In yet another embodiment, a method for interfacing with a PDC via asystem management bus includes sending a power delivery configuration, apower delivery command, and a power delivery event configuration to thePDC. The method further includes receiving a power delivery status, anda power delivery message from the PDC. The power delivery configurationcomprises voltage and current settings. The power delivery commandinstructs the PDC to send a first power delivery message to a USB portpartner of the PDC, and wherein the first power delivery messagecomprises a hard reset request. The power delivery event configurationcomprises a hard reset event. The power delivery status comprises a hardreset status indicating an occurrence of the hard reset event at thePDC. The received power delivery message comprises a power capability ofthe USB port partner.

BRIEF DESCRIPTION OF THE DRAWINGS

For a detailed description of exemplary embodiments of the invention,reference will now be made to the accompanying drawings in which:

FIG. 1 shows a block diagram of a USB connection system in accordancewith various embodiments;

FIG. 2 shows a block diagram of a USB PD system in accordance withvarious embodiments;

FIG. 3 shows a block diagram of a USB PD controller system in accordancewith various embodiments;

FIG. 4 shows a block diagram of logical layers in a USB PD system inaccordance with various embodiments;

FIG. 5 shows a protocol diagram of an initialization method between ahost controller, a PDC, and a far-end device in accordance with variousembodiments;

FIG. 6 shows a protocol diagram of a re-initialization method between ahost controller and a PDC in accordance with various embodiments;

FIG. 7 shows a protocol diagram of an event alert method between a hostcontroller and a PDC in accordance with various embodiments; and

FIG. 8 shows a protocol diagram of a PDC control method between a hostcontroller, a PDC, and a far-end device in accordance with variousembodiments.

DETAILED DESCRIPTION

The following discussion is directed to various embodiments of theinvention. Although one or more of these embodiments may be preferred,the embodiments disclosed should not be interpreted, or otherwise used,as limiting the scope of the disclosure, including the claims. Inaddition, one skilled in the art will understand that the followingdescription has broad application, and the discussion of any embodimentis meant only to be exemplary of that embodiment, and not intended tointimate that the scope of the disclosure, including the claims, islimited to that embodiment.

The USB PD specification may define a communication protocol to addressthe emergence of employing USB ports primarily for power delivery alongwith some data transfer instead of primarily for data transfer alongwith some power delivery. The USB PD specification may define acommunication link between ports connected via USB PD cables andconnectors. The communication may be designed to be half-duplex andpacket based. The packets may comprise information that enables a pairof connected ports (e.g. a sink port and a source port) to communicateand negotiate voltage and/or current that the source port may provide tothe sink port. The underlying communication defined in the USB PDspecification may be a binary Frequency Shift Keying (FSK). The powerdelivery communication may occur independently from USB datacommunication over a USB cable comprising a power delivery wire, V_(BUS)and a data wire, where the USB PD communication may be over the powerdelivery wire and the USB data communication may be over a data wire.The USB PD specification may enable a device to negotiate power ofvarying amount based on requirement instead of supplying a defaultamount of power to all devices. For example, a low power headphone maybe plugged into a laptop via a USB PD port and may negotiate for lesspower (e.g. about 2 W) than a default power. In contrast, a monitor maybe plugged into the laptop and negotiate for a high power of about 100W. In addition, power delivery may respond to system power requirementchanges and/or requests from a far-end device by increasing ordecreasing power consumption accordingly.

A USB PD port may act as a power provider to deliver power or a consumerto sink power. The USB PD specification may define a procedure for aport to switch role. For example, a USB PD port may act as aProvider/Consumer (P/C), where the P/C may be a provider that may switchrole to be a consumer. Conversely, a USB PD port may act as aConsumer/Provider (C/P), where the C/P may be a consumer that may switchrole to be a provider. It should be noted that in the presentdisclosure, a USB PD port may be referred to as a USB port or a port,and a USB PD port partner (e.g. connecting to a local USB device) may bereferred to as a far-end device, a far-end port, or a port partner.

Embodiments of the host interface for USB PD disclosed herein includes aset of commands for exchanging USB PD information between a hostcontroller (e.g. an embedded controller) and a USB PDC. The PDC mayimplement functionalities defined in the USB PD specification and may berealized in an Integrated Circuit (IC). The host controller may manageand control the PDC for power delivery. The commands may be communicatedover a bus interface comprising a data line and a clock line. In someembodiments, the bus interface may employ an Inter-Integrated Circuit(I2C) bus interface, a System Management Bus (SMBus) interface asdefined in the SMBus Specification version 2.0, which is incorporatedherein by reference as if reproduced in its entirety, or any other businterface configured to communicate across Integrated Circuit (ICs). Insuch embodiment, the PDC may be a slave module to the host controller,where the host controller may issue commands to the PDC. For example, ahost controller may issue a write command or a read command to a PDC. Awrite command may cause the PDC to initialize some parameters or performa task and a read command may cause the PDC to return a status or areceived message. In some embodiments, the bus interface may include anadditional alert line, which may allow the PDC to notify the hostcontroller when some events occur. The host controller may enable ordisable an event alert by configuring the PDC. In some embodiments, aPDC may comprise a non-volatile memory (e.g. Electrical ErasableProgrammable Read-Only Memory (EEPROM)) and a host controller mayrequest the PDC to store parameters into the non-volatile memory.

FIG. 1 shows a block diagram of a USB connection system 100 inaccordance with various embodiments. System 100 may comprise a USB hub110 and a plurality of devices 120, 130, and 140. USB hub 110 may be anydevice configured to expand a single USB port (e.g. connecting to a hostsystem) into multiple USB ports available for device connections. USBhub 110 may comprise a plurality of USB ports 111 (e.g. Port #1 to Port#N). Devices 120, 130, and 140 may be any device configured tocommunicate to a host system via the USB PD communication protocol (e.g.power delivery) and/or the USB communication protocol (e.g. datatransfer). For example, a power adaptor may implement the USB PDcommunication protocol but not the USB communication protocol, whereas asmartphone or a tablet may implement both the USB PD and USBcommunication protocols. Each device 120, 130, or 140 may comprise atleast one USB port 121, 131, or 141, respectively, for USBcommunication. For example, devices 120 and 140 may be connected to ahost system via USB hub 110, where a port 121 of devices 120 may beconnected to a port 111 of USB hub 110 and a port 141 of devices 140 maybe connected to another port 111 of USB hub 110. USB devices may bechained, for example, device 130 may be connected to USB hub 110 viadevice 120.

In some embodiments, USB port 111, 121, 131, and/or 141 may be USB PDports and may be a provider that sources power or a consumer that sinkspower. In some other embodiments, a USB port 111, 121, 131, and/or 141may be a P/C port or a C/P port. A P/C port may be a provider thatsources power and later switches to a consumer that sinks power, whereasa C/P port may be a consumer that sinks power and later switches to aprovider that sources power. A provider may derive power sources from aplurality of power sources, such as an external power source (e.g.Alternating Current (AC) power), a power storage (e.g. a battery),and/or other ports (e.g. a bus-powered hub). A consumer may utilizepower to operate internal functions, power an attached device, and/orstore power to some power storages (e.g. battery).

FIG. 2 shows a block diagram of a USB PD interconnection system 200 inaccordance with various embodiments. System 200 may comprise a source210 interconnected to a sink 220 via a cable 230. Source 210 maycomprise a transmitter (Tx) 211, a receiver (Rx) 212, a cable detectionmodule 213, a power delivery wire V_(BUS) 214, and a coupling capacitor215. The transmitter 211 and the receiver 212 may be AC coupled to thepower delivery wire V_(BUS) 214 via the coupling capacitor 215. Thetransmitter 211 and receiver 212 may be configured to transmit andreceive signal, respectively, over the power delivery wire V_(BUS) 214.The cable detection module 213 may be coupled to the transmitter 211 andthe receiver 212 and configured to detect the type of an attached cable.Source 210 may further comprise a power supply source 216 and a couplingimpedance 217, which separates the power supply source 216 from thepower delivery wire V_(BUS) 214, the transmitter 211, and the receiver212. Similarly, the sink 220 may be coupled and configured insubstantially similar mechanisms as source 210. However, the sink 220may comprise a load 227 instead of a power supply 216 as in source 210.

FIG. 3 shows a block diagram of a USB PD system 300 in accordance withvarious embodiments. USB PD system 300 may be a provider that sourcespower or a consumer that sinks power. USB PD system 300 may comprisesubstantially similar components as in source 210 or sink 220. However,USB PD system 300 may be intended to illustrate a source 210 or a sink220 implemented via a PDC 310 and a host controller 320. In USB PDsystem 300, PDC 310 may be connected to a plurality of power switches330 and a USB receptacle 340 inserted with a cable 370.

PDC 310 may be any device and/or IC configured to implement thecommunication protocol defined in the USB PD specification. PDC 310 maycomprise a transmitter (Tx) 311, a receiver (Rx) 312, and a cable-typedetection module 313, which may be substantially similar to transmitter211, receiver 212, and cable detection module 213. PDC 310 may furthercomprise a microcontroller (MCU) 314, which may implement a powerdelivery communication stack as defined in the USB PD specification forpower delivery message negotiations. The transmitter 311 and thereceiver 312 may be configured to implement a half-duplex frequencyshift keying (FSK) modem for the transmission or reception of the powerdelivery negotiation messages over a power delivery wire V_(BUS) 350(e.g. power delivery wire V_(BUS) 214) that connects PDC 310 to afar-end port (e.g. source 210 or sink 220) via USB receptacle 340 andcable 370. PDC 310 may further comprise a receive squelch detector 315,which may be configured to detect signal level on the power deliverywire V_(BUS) 350 and may determine the presence of data communication onthe power delivery wire V_(BUS) 350 based on the detected signal level.PDC 310 may switch the power switches 330 in or out depending on powerdelivery negotiations and/or configurations. For example, PDC 310 mayswitch to a 20 Volt (V) power supply at one time and may switch to a 5Vpower supply at another time upon a request. In addition, PDC 310 mayswitch to sink power instead of source power (e.g. to charge a battery)upon a role swap request. In some embodiments, PDC 310 may furthercomprise a non-volatile memory, which may store configurationsparameters.

Host controller 320 may be any device configured to control PDC 310. Forexample, host controller 320 may be an embedded controller, a MCU, orany other processors. Host controller 320 may be coupled to PDC 310 viaa bus interface 360. In an embodiment, bus interface 360 may be a SMBusinterface comprising a clock line and a data line as defined in theSMBus specification. In such embodiment, host controller 320 may be amaster and PDC 310 may be a slave, where the host controller 320 mayissue a write command or a read command to PDC 310. During a writecommand, the host controller 320 may place a slave address, a commandcode, a write transaction type, and a data with variable lengths on thedata line. During a read command, host controller 320 may place a slaveaddress, a command code, a read transaction type, and a data withvariable lengths on the data line. The read transaction may cause thehost controller 320 and the PDC 310 to switch transmit and receivedirection, thus allowing PDC 310 to place data on the data line. The businterface 360 may further comprise an alert signal to enable PDC 310 tonotify host controller 320 when some events occur. Host controller 320may be configured to implement a set of host commands to configure PDC310, manage PDC 310 power delivery, and retrieve statuses from PDC 310.Host controller 320 may perform some additional actions based onstatuses read from PDC 310.

FIG. 4 shows a block diagram of logical layers in a USB PD system 400 inaccordance with various embodiments. System 400 may comprise a physicallayer 410, a protocol 420, a policy engine 430, a device policy manager440, a system policy manager 450, and a cable-type detection 460 asdefined in the USB PD specification. Physical layer 410 may beconfigured to handle transmission and reception of power deliverymessages on a power delivery wire (e.g. power delivery wire V_(BUS)350). Protocol 420 may be configured to exchange power delivery messagesbetween USB PD devices (e.g. between source 210 and sink 220). Policyengine 430 may be configured to implement a local policy for powerdelivery at a USB PD device. Device policy manager 440 may be configuredto manage USB PD resources within a USB PD device and may span acrossone or more USB ports (e.g. ports 111, 121, 131, or 141). System policymanger 450 may be configured to manage system wide power delivery in aUSB PD interconnection system (e.g. USB PD interconnection system 200)across multiple providers and/or consumers. Cable-type detection 460 maybe configured to detect the type of attached cables via physical layer410. Cable-type detection 460 may provide the detected cable informationto device policy manager 440. The device policy manager 440 may thenfurther manage resources according to the cable information. It shouldbe noted that system policy manager 450 may be optional in a USB PDsystem.

In some embodiments, a PDC (e.g. 310) may implement physical layer 410,protocol layer 420, and policy engine 430, but may not fully implementdevice policy manager 440. In such embodiments, a device policy manager440 may be fully or partially implemented on a host controller (e.g.host controller 320) external to the PDC. As such, the host controllermay communicate with the PDC to jointly realize complete USB PDfunctionalities. For example, a host controller may configure a PDC,request the PDC to issue power delivery messages to a connected far-enddevice, read PDC statuses, read far-end messages received by the PDC,and/or perform other actions locally in response to messages receivedfrom the far-end device. The USB PD specification defines two types ofprotocol messages, control messages and data messages. Control messagesmay be messages for managing message flow between a pair of USB PD ports(e.g. GoodCRC, Accept, Reject messages, etc.) or for exchanging commands(e.g. GotoMin, Get_Sink_Cap, Get_Source_Cap, Swap messages, etc.)between a pair of USB PD ports. Data messages may be messages forcarrying data information for power delivery negotiation (e.g.SourceCapabilities, SinkCapabilities, Request messages, Built inSelf-Test (BIST), vendor defined, etc.). For example, aSourceCapabilities or SinkCapabilities message may comprise a pluralityof power data objects (PDOs) and a Request message may comprise aplurality of request data objects (RDOs). A PDO may comprise current,voltage, and/or power limits (e.g. maximum, minimum, peak, and/or oroperating) for a single power supply (e.g. fixed, variable, or battery).A provider port may send a PDO to indicate current, voltage, and/orpower that the provider port may provide. A consumer port may send a PDOto indicate current, voltage, and/or power that the consumer port mayoperate on. In addition, a consumer port may send a RDO in response to aPDO sent by the provider port to negotiate current, voltage, and/orpower that the consumer port may require. A PDC may fully manage andcontrol the flow control messages as the flow control messages may beexchanged entirely between the PDC and a connected far-end device,whereas the command control messages and the data messages may bepartially driven by a host controller. FIGS. 5-8 are intended toillustrate some examples of interactions between a host controller and aPDC when implementing some of the USB PD functionalities. Theinteractions may be described with the host controller acting as amaster to the PDC (e.g. over a SMBus interface), where all commands(e.g. read or write transactions) may be initiated by the hostcontroller and the PDC may notify the host controller via an alertsignal. It should be noted that the mechanisms for a PDC to alert thehost may be alternatively configured as determined by a person ofordinary skill in the art to achieve the same functionalities.

FIG. 5 shows a protocol diagram of an initialization method 500 betweena host controller (e.g. host controller 320), a PDC (e.g. PDC 310), anda far-end device in accordance with various embodiments. In method 500,the host controller and the PDC may reside on a local device, which mayact as a source or a sink depending on configuration parameters. Method500 may begin with the host controller sending a set of initializationparameters and negotiation parameters to configure the PDC at step 510.Initialization parameters may include PDOs for a source, PDOs for asink, and/or RDOs for a sink. The source PDOs may be employed by asource when sending a source capability message while the sink PDOs andthe RDOs may be employed by a sink when sending a sink capabilitymessage and requesting for power, respectively. At step 520, the PDC maysave the parameters locally. At step 530, the host controller may sendan enable command to the PDC to enable the PDC to begin operating withthe initialization and negotiation parameters. At step 540, the PDC mayestablish a PD connection, exchange capabilities with the far-end deviceand/or request power from the far-end device according to the protocoldefined in the USB PD specification.

FIG. 6 shows a protocol diagram of a re-initialization method 600between a host controller (e.g. host controller 320) and a PDC (e.g. PDC310) in accordance with various embodiments. Method 600 may begin afterthe PDC is initialized (e.g. after step 530 of method 500 is completed).At step 610, the host controller may send a re-initialization command tothe PDC to start a re-initialization process. At step 620, the PDC mayprepare to enter a re-initialization state. For example, the PDC mayabort an active PD contract. At step 630, the host controller may sendupdated initialization parameters to the PDC. At step 640, the PDC maysave the parameters locally. At step 650, the host controller may sendan enable command to the PDC to activate the updated initializationparameters. Upon receiving the enable command, the PDC may operateaccording to updated initialization parameters.

FIG. 7 shows a protocol diagram of an event alert method 700 between ahost controller (e.g. host controller 320) and a PDC (e.g. PDC 310) inaccordance with various embodiments. Method 700 may begin with the hostcontroller sending an alert status mask command to the PDC to registerwith the PDC for some events at step 710. Some examples of events mayinclude a hardware reset event, a plug status event, an error event, amessage received event, and/or a BIST mode event. At step 720, the PDCmay save the registered events locally. At step 730, the PDC may detectan event that has been registered by the host controller. At step 740,the PDC may assert an alert signal (e.g. an additional signal separatedfrom data transaction) to notify the host controller of an event. Atstep 750, the host controller may issue a read command to the PDC toretrieve the reason of alert. At step 760, the PDC may return the reasonof alert to the host controller. The host controller may take variousactions depending on the received event. In one embodiment, the hostcontroller may perform some actions based on the retrieved event. Inanother embodiment, the host controller may further retrieve eventdetail (e.g. type of hard reset, type of cable detected, or type oferror detected) by issuing a command to the PDC as shown in step 771 andthe PDC may return the event detail to the host controller at step 772.In yet another embodiment, the event detail may trigger the hostcontroller to retrieve further information from the PDC, such asretrieving a message from the PDC, by issuing a read message command tothe PDC as shown in step 773, and the PDC may return the receivedmessage to the host controller at step 774. The host controller may ormay not take further actions depending on the event detail or themessage read. As such, steps 771-774 may be optional and may depend onthe received event.

FIG. 8 shows a protocol diagram of a control method 800 between a hostcontroller (e.g. host controller 320), a PDC (e.g. PDC 310), and afar-end device in accordance with various embodiments. In method 800,the host controller and the PDC may reside on a local device. Method 800may begin with the host controller sending a command to the PDC torequest capability of a connected port partner at step 810. At step 820,the host controller may send an alert status mask command to the PDC toregister with the PDC for a received message event. At step 830, the PDCmay send the capability request message (e.g. Get_Source_Cap) to thefar-end device. At step 840, the PDC may receive a capability responsefrom the far-end device. At step 850, the PDC may assert an alert signalto notify the host controller of a received message. At step 860, thehost controller may issue a read command to the PDC to retrieve thereason of alert. At step 870, the PDC may return the reason of alert(e.g. a capability message is received) to the host controller. At step880, the host controller may issue a command to retrieve the receivedcapability message. At step 890, the PDC may send the received messageto the host controller.

Table 1 shows an embodiment of host interface commands that may beemployed by a host controller (e.g. host controller 320) to communicatewith a PDC (e.g. PDC 310) in a USB PD system (e.g. USB PD system 300) toperform USB power delivery functionalities. The host controller and thePDC may reside on a local device and may negotiate power deliveryoptions with a connected far-end device. The PDC may implement the USBPD communication protocol (e.g. physical layer and protocol layer) asdefined in the USB PD specification and the host controller mayconfigure and manage the PDC. Some examples of host interface commandsmay include sending PDC configurations (e.g. initialization parametersand negotiation parameters) and PDC controls (e.g. local actions andfar-end actions), and retrieving PDC statuses (e.g. events and receivedmessages). In Table 1, a read command from the host controller may beindicated as (R) and a write command from the host controller may beindicated as (W). It should be noted that the code values, commandnames, data values, and/or bit positions described in the followingembodiments may be for illustrative purpose. In addition, theinteractions may be described with the host controller acting as amaster to the PDC (e.g. over a SMBus interface) and initiating readand/or write commands. However, the interface commands may bealternatively configured as determined by a person of ordinary skill inthe art to achieve the same functionalities.

TABLE 1 List of Host Controller Interface Commands Code Command R/WDescription 00h STATUS_ALERT R Reasons of alert. 01h CLEAR_STATUS WClears all bits in STATUS_ALERT 02h STATUS_USB_PD R Alert events 03hSTATUS_SMBUS_SLAVE R SMBus status 05h ENABLE W Enables PDC 06hREINITIALIZE W Sets PDC in re-initialization mode 07h VOLTAGE_INFO RVoltage levels of USB PD system 08h ACTIVE_CONTRACT_PDO R PDO of acurrent contract 09h ACTIVE_CONTRACT_RDO R RDO of a current contract 0AhUSB_PD_CONTROL W Commands PDC to perform an action 0Bh VENDOR_SPECIFICR/W Vendor specific info 0Ch STORE_CONFIGURATION W Requests PDC to storeconfiguration to a non-volatile memory 0Dh RESET W Resets PDC 0EhDEVICE_ID R PDC hardware and firmware version 0Fh SPECIFICATION_REVISIONR Supported USB specification revision 10h SOURCE_PDO_BATTERY R/WInitialization parameters for battery power supply 11h CAPABILITIES RPDOs returned by a partner device 19h STATUS_ALERT_MASK R/W Alert eventmask 1Ah NEGOTIATION_INFO R/W Negotiation Parameters 1BhSOURCE_PDO_FIXED_OR_VAR R/W Initialization parameters for fixed and/orvariable power supply 1Ch SINK_PDO_FIXED R/W Initialization parametersfor a sink to operate with fixed power supply 1Dh SINK_PDO_VAR R/WInitialization parameters for a sink to operate with variable powersupply 1Eh SINK_PDO_BATTERY R/W Initialization parameters for a sink tooperate with battery power supply 21h INITIALIZATION R/W Otherinitialization parameters for PDC configuration 22h LOW_POWER R/W Lowerpower mode configuration parameters

In an embodiment, a STATUS_ALERT command may be issued by a hostcontroller to retrieve an alert status from a PDC after receiving analert signal from the PDC. For example, the STATUS_ALERT command may beindicated by a command code of 0x00 in hexadecimal format and the alertstatus may be about two octets long. The alert status may indicate theevent that causes the PDC to send an alert signal to the hostcontroller. Each event may be indicated by about 1-bit. For example, abit-value of one may indicate the PDC detected an occurrence of theevent and a bit-value of zero may indicate otherwise. Some of the eventsmay comprise more detailed information, which may be retrieved by thehost controller via a STATUS_USB_PD command, which may be explained morefully below. The following table lists some examples of the events thatthe PDC may notify the host controller:

TABLE 2 List of Alert Event Types Bit position Alert status b0 HardResetb1 ErrorType b2 VendorSpecific b3 MsgType1 b4 BISTMode b5 SMBusSlave b6PlugStatus b7 ExcessiveIRDrop b8 NegotiationUpdate b9StoreConfigurationComplete  b10 AwokenByHost controller  b11 MsgType2

The PDC may notify the host controller of a HardReset event when a hardreset has been performed. For example, the HardReset event may beindicated by setting bit zero of the alert status to a value of one. Thehost controller may further retrieve the HardReset event value todetermine the type of hard reset performed by issuing a STATUS_USB_PDcommand, which may be discussed more fully below.

The PDC may notify the host controller of an ErrorType event when thePDC detects an error. For example, the ErrorType event may be indicatedby setting bit one of the alert status to a value of one. The hostcontroller may further retrieve the ErrorType event value to determinethe type of errors by issuing a STATUS_USB_PD command, which may bediscussed more fully below.

The PDC may notify the host controller of a VendorSpecific event toreport a vendor specific message related events (e.g. sent, received).For example, the VendorSpecific event may be indicated by setting bittwo of the alert status to a value of one. The host controller mayfurther retrieve the VendorSpecific event value to determine the type ofvendor message events by issuing a STATUS_USB_PD command, which may bediscussed more fully below.

The PDC may notify the host controller of a MsgType1 event when the PDCreceives a message from the far-end port. For example, the MsgType1event may be indicated by setting bit three of the alert status to avalue of one. The host controller may further retrieve the MsgType1event value to determine the type of message receive by issuing aSTATUS_USB_PD command, which may be discussed more fully below. The hostcontroller may take further action depending on the message type. Forexample, when the received message is a GotoMin message, the hostcontroller may configure the system to draw less current from theV_(BUS) (e.g. power delivery wire V_(BUS) 350).

The PDC may notify the host controller of a BISTMode event when the PDCenters a BIST mode physical layer test. For example, the BISTMode eventmay be indicated by setting bit four of the alert status to a value ofone. The PDC may notify the host controller of a SMBusSlave event whenthe PDC detects an error at the SMBus interface. For example, theSMBusSlave event may be indicated by setting bit five of the alertstatus to a value of one. The PDC may notify the host controller of aPlugStatus event when the PDC detects a change in an USB plug status(e.g. insert or removal). For example, the PlugStatus event may beindicated by setting bit six of the alert status to a value of one. Thehost controller may further retrieve the PlugStatus event value todetermine the type of plug status changes by issuing a STATUS_USB_PDcommand, which may be discussed more fully below.

The PDC may notify the host controller of an ExcessivelRDrop event whenthe PDC measures an excessive voltage drop on the V_(BUS) wire. Forexample, the ExcessivelRDrop event may be indicated by setting bit sevenof the alert status to a value of one. When the host controller receivesthe ExcessivelRDrop event, the host controller may configure the systemto draw less current from the V_(BUS) wire.

The PDC may notify the host controller of a NegotiationUpdate event whenthe PDC has an updated power contract after negotiating with a far-endport. For example, the NegotiationUpdate event may be indicated bysetting bit eight of the alert status to a value of one. The hostcontroller may further retrieve the NegotiationUpdate event value todetermine the type of contract changes by issuing a STATUS_USB_PDcommand, which may be discussed more fully below.

The PDC may notify the host controller of a StoreConfigurationCompleteevent when the PDC has successfully stored configuration parameters to anon-volatile memory. For example, the StoreConfigurationComplete eventmay be indicated by setting bit nine of the alert status to a value ofone. The PDC may notify the host controller of an AwokenByHostcontroller event to indicate that the PDC has been woken up (e.g. from asleep mode) by the host controller either via SMBus traffic or throughan assertion of a designed signal. For example, the AwokenByHostcontroller event may be indicated by setting bit ten of the alert statusto a value of one.

In an embodiment, a CLEAR_STATUS command may be issued by a hostcontroller to clear all the bits in the alert status. For example, theCLEAR_STATUS command may be indicated by a command code of 0x01 inhexadecimal format and the command may be about one octet long.

In an embodiment, a STATUS_USB_PD command may be issued by a hostcontroller to retrieve a USB PD status from a PDC. For example, theSTATUS_USB_PD command may be indicated by a command code of 0x02 inhexadecimal format and the USB PD status may be about four octets long.As described herein above, after the host controller is notified by thePDC of a HardReset event, the host controller may retrieve more detailinformation of the HardReset event by issuing the STATUS_USB_PD command.The following table lists some examples of HardReset event values:

TABLE 3 List of HardReset Event Values Event Value Description 000b nohard reset 001b hard reset signaling received from far-end 010b hardreset request from device policy manager 011b hard reset done for safety100b hard reset required by the policy engine (signaling sent tofar-end)The PDC may indicate a HardReset event value by about 3-bits in the USBPD status. For example, an event value of zero may indicate no hardreset is performed at the PDC. An event value of one may indicate thePDC performed a hard reset caused by receiving a hard reset request froma far-end port. An event value of two may indicate the PDC performed ahard reset due to a hard reset request received from a local devicepolicy manager. An event value of three may indicate the PDC performed ahard reset due to safety reason. An event value of four may indicate thePDC performed a hard reset due to a hard reset request received from apolicy engine and the PDC has signaled the far-end port of the hardreset.

As described herein above, after the host controller is notified by thePDC of an ErrorType event, the host controller may retrieve more detailinformation of the ErrorType event by issuing the STATUS_USB_PD command.The following table lists some examples of ErrorType event values:

TABLE 4 List of ErrorType Event Values Event Value Description 0000b Noerror 0001b USB PD device with incompatible specification version 0010bHost controller gave an invalid command 0011b USB PD source cannotprovide an acceptable voltage and/ or current. 0100b USB PD source canprovide acceptable voltage and current, but not at the present time.0101-1111b ReservedThe PDC may indicate an ErrorType event value by about 4-bits in the USBPD status. For example, an event value of zero may indicate no error isdetected at the PDC. An event value of one may indicate the PDC detectsa connected USB PD device with an incompatible specification version. Anevent value of two may indicate receiving an invalid command from thehost controller (e.g. a GotoMin command when PDC's contract does notsupport GotoMin). An event value of three may be indicated when the PDCis a sink and a connected USB source may not provide an acceptablevoltage and/or current (e.g. a Reject message is received for arequested contract). The host controller may further retrieve thecontract received by issuing an ACTIVE_CONTACT_PDO command, which may bediscussed more fully below. An event value of four may be indicated whenthe PDC is a sink and a connected USB source may provide an acceptablevoltage and/or current, but not at the present time.

As described herein above, after the host controller is notified by thePDC of a PlugStatus event, the host controller may retrieve more detailinformation of the PlugStatus event by issuing the STATUS_USB_PDcommand. The following table lists some examples of PlugStatus eventvalues:

TABLE 5 List of PlugStatus Event Values Event Value Description 0000b nocable 0001b Legacy A plug inserted 0010b Legacy B plug inserted 0011b Noplug or Legacy B plug inserted 0100b PD B Plug (Micro or Standard)inserted 0101b PD A Plug (Micro or Standard) inserted 0110b Unplugged0111b Low-Power Micro-A Plug 1000b Legacy A plug inserted or no plug1001b Legacy A plug inserted, device at far-end has ability to source.1010b B plug with a non-PD device at the far-end inserted 1101b PD APlug (Micro or Standard) inserted, device at far- end has ability tosource. 1110b Reserved 1111b Low-Power Micro-A Plug, device at far-endhas ability to source.The PDC may indicate a PlugStatus event value by about 4-bits in the USBPD status representing the different types of USB plug is inserted orremoved. For example, an event value of zero may indicate no cableinsertion is detected by the PDC. An event value of one may indicate thePDC detects an insertion of a legacy A plug. An event value of two mayindicate the PDC detects an insertion of a legacy B plug. An event valueof three may indicate the PDC detects an insertion of a legacy B plug ormay not detect any plug insertion. An event value of four may indicatethe PDC detects an insertion of a micro PD B plug or a standard PD Bplug. An event value of five may indicate the PDC detects an insertionof a micro PD A plug or a standard PD A plug. An event value of six mayindicate the PDC detects a USB plug is removed. An event value of sevenmay indicate the PDC detects an insertion of a low power micro PD Aplug. An event value of eight may indicate the PDC detects an insertionof a legacy A plug or no plug. An event value of nine may indicate thePDC detects an insertion of a legacy A plug and a far-end port may beable to source power. An event value of ten may indicate the PDC detectsan insertion of a legacy B plug and the far-end port may not support PD.An event value of thirteen may indicate the PDC detects an insertion ofa micro PD B plug or a standard PD B plug and the far-end port maysource power. An event value of fifteen may indicate the PDC detects aninsertion of a low power micro PD A and the far-end port may sourcepower.

When a host controller issues a USB_PD_CONTROL command to request thePDC to perform an action, the host controller may retrieve PDC controlstatus in response to the requested action by issuing the STATUS_USB_PDcommand. The following table lists some examples of PDC control statusvalues:

TABLE 6 List of PDC Control Status Values Status Value Description 000bNot processing any USB PD Control command 001b Last USB PD Controlcommand in process 010b Last USB PD Control command completedsuccessfully 011b Last USB PD Control command failed 100b Waiting forhost controller 101b Transitioning Power SupplyThe PDC may indicate a PDC control status value by about 3-bits in theUSB PD status. For example, a status value of zero may indicate the PDCis not processing any USB PD control command from the host controller. Astatus value of one may indicate the PDC is processing a last USB PDcontrol command issued by the host controller. A status value of two mayindicate the PDC has completed the processing of a last USB PD controlcommand issued by the host controller. A status value of three mayindicate the PDC has failed to process a last USB PD control commandissued by the host controller. A status value of four may indicate thePDC is waiting for the host controller to respond. For example, a PDCmay be waiting on the host controller to provide a list of sourcecapabilities for sending to a far-end device or to provide instructionsto select a capability during capability evaluation. A status value offive may indicate the PDC is transitioning to another power supply.

As described herein above, after the host controller is notified by thePDC of a VendorSpecific event, the host controller may retrieve moredetail information of the VendorSpecific event by issuing theSTATUS_USB_PD command. The following table lists some examples ofVendorSpecific event values:

TABLE 7 List of VendorSpecific Event Values Event Value Description 00bno vendor defined message activity 01b Vendor defined message sendfailed 10b Vendor defined message received 11b Vendor defined messagesent successfully.The PDC may indicate a VendorSpecific event value by about 2-bits in theUSB PD status. For example, an event value of zero may indicate the PDCdetects no vendor specific message activity. An event value of one mayindicate the PDC fails to send a vendor specific message. An event valueof two may indicate the PDC receives a vendor specific message from thefar-end port. An event value of three may indicate the PDC successfullysent a vendor specific message.

As described herein above, after the host controller is notified by thePDC of a MsgType1 event or a MsgType2 event indicating a messagereceived from the far-end port, the host controller may retrieve moredetailed information of the received message types by issuing theSTATUS_USB_PD command. The received message may be a control message ora data message as defined in the USB PD specification. For example, acontrol message may be differentiated from a data message by employing1-bit from the USB PD status, where a bit-value of one may indicate adata message and a bit-value of zero may indicate a control message. Themessage type may be indicated by about 4-bits and the message typevalues may be as defined in the USB PD specification. The hostcontroller may further retrieve information of the received messagecontent from the USB PD status. For example, the host controller mayretrieve a peak power value embedded in a SourceCapability message or ahigher capability value embedded in a SinkCapability message. Inaddition, a host controller may retrieve a USB communication capablevalue, an USB communication suspend support value, a dual role value,and/or any other fields embedded in a SourceCapability message or aSinkCapability message. The host controller may also retrieve thecomplete contract by issuing an ACTIVE_CONTRACT_PDO command and/or anACTIVE_CONTRACT_RDO command, which may be discussed more fully below.

As described herein above, after the host controller is notified by thePDC of a NegotiationUpdate event, the host controller may retrieve moredetailed information of the NegotiationUpdate event by issuing theSTATUS_USB_PD command. The following table lists some examples ofNegotiationUpdate event values:

TABLE 8 List of NegotiationUpdate Event Values Event Value Description00b No update 01b New contract and stable power state 10b The source isoffering new capabilities that would increase voltage.The PDC may indicate a NegotiationUpdate event value by about 2-bits inthe USB PD status. For example, an event value of zero may indicate thePDC may not have an updated contract to update. An event value of onemay indicate the PDC has negotiated a new contract and power in a stablestate. The host controller may further retrieve the updated contract byissuing an ACTIVE_CONTRACT_PDO command, which may be discussed morefully below. An event value of two may be indicated when the PDC is asink and receives a contract from a USB source indicating that the USBsource may increase voltage.

In an embodiment, a STATUS_SMBUS_SLAVE command may be issued by a hostcontroller to a PDC to retrieve SMBus statuses. For example, theSTATUS_SMBUS_SLAVE command may be indicated by a command code of 0x03 inhexadecimal format and the SMBus slave status may be about one octetlong. The following table lists some examples of SMBus slave statuses:

TABLE 9 List of SMBus Status Values Bit position SMBus Status b0 Invalidcommand received b1 Invalid data received b2 Invalid packet error check(PEC) received b3 Write to a read-only command b4 Incorrect block sizeb5 Received too much data b6 Address misuse b7 Some other unexpectederror

The PDC may indicate an invalid command is received from the hostcontroller, for example, by setting bit zero of the SMBus status to avalue of one. The PDC may indicate an invalid data is received from thehost controller, for example, by setting bit one of the SMBus status toa value of one. The PDC may indicate an invalid packet error check (PEC)is received from the host controller, for example, by setting bit two ofthe SMBus status to a value of one. The PDC may indicate the hostcontroller send a read-only command with a transaction type of write,for example, by setting bit three of the SMBus status to a value of one.The PDC may indicate an incorrect block size when the block size writtenby the host controller does not match the size of the command, forexample, by setting bit four of the SMBus status to a value of one. ThePDC may indicate when the number of incoming data bytes on the SMBusexceeds the expected size, for example, by setting bit five of the SMBusstatus to a value of one. The PDC may indicate the host controllermisuse a secondary address for a command that is not a read STATUS_ALERTcommand when responding to an alert event, for example, by setting bitsix of the SMBus status to a value of one. The PDC may indicate someother unexpected error on the SMBus, for example, by setting bit sevenof the SMBus status to a value of one.

In an embodiment, an ENABLE command may be issued by a host controllerto enable a PDC to begin operating with the initialization parameters.For example, the ENABLE command may be indicated by a command code of0x05 in hexadecimal format and may be about one octet long. It should benoted that some dynamic initialization parameters may be modifiedsubsequent to an ENABLE command.

In an embodiment, a REINITIALIZE command may be issued by a hostcontroller to indicate the host controller may start to re-initializePDC parameters. For example, the REINITIALIZE command may be indicatedby a command code of 0x06 in hexadecimal format and may be about oneoctet long. It should be noted that when the PDC receives a REINITIALIZEcommand, the PDC may be set to a state ready for parameterre-initialization and may end a current contract.

In an embodiment, a VOLTAGE_INFO command may be issued by a hostcontroller to retrieve PDC voltage information. For example, theVOLTAGE_INFO command may be indicated by a command code of 0x07 inhexadecimal format and may be about four octets long. The followingtable lists some examples of voltage information:

TABLE 10 V_(BUS) Voltage information Bit Position Description b0-b9Present voltage b10-b19 Reference voltage b20-b29 Reference voltage −present voltage b31 1: value, 0: validThe voltage information may comprise a present voltage, a referencevoltage, and a difference between a reference voltage and a presentvoltage, which may all be about 10-bits long. For example, the presentvoltage may indicate a current voltage measurement on the V_(BUS) wire,a reference voltage may indicate a voltage measurement on the V_(BUS)wire at a time when current drawing is small (e.g. small IR drop), andthe difference between the reference voltage and the present voltage mayindicate the IR drop on the V_(BUS) wire.

In an embodiment, an ACTIVE_CONTRACT_PDO command may be issued by a hostcontroller to retrieve a current contract negotiated by a PDC, which maycarry the contract information as defined in the USB PD specification.For example, the ACTIVE_CONTRACT_PDO command may be indicated by acommand code of 0x08 in hexadecimal format and may be about four octetslong. It should be noted that a current contract value of all zeroes mayindicate no contract is present. The contract information returned viathe ACTIVE_CONTRACT_PDO command may include the maximum and the minimumvoltage or a nominal voltage if the supply type is fixed. The contractinformation may also include a maximum current or a maximum power. Othercontract information that may be present is a Dual-Role bit indicatingwhether a device may be a source and a sink, a USB Suspend Support bit,an externally powered bit, a USB Communications capable bit, and a PeakPower bit field.

In an embodiment, an ACTIVE_CONTRACT_RDO command may be issued by a hostcontroller to retrieve a contract currently requested by a PDC when thePDC is a sink, which may carry the request information as defined in theUSB PD specification. For example, the ACTIVE_CONTRACT_RDO command maybe indicated by a command code of 0x09 in hexadecimal format and may beabout four octets long. It should be noted that a request contract valueof all zeroes may indicate no request contract is present. The contractinformation returned to the ACTIVE_CONTRACT_RDO command may include anoperating current, a maximum operating current, a minimum operatingcurrent, an operating power, a maximum operating power, and/or a minimumoperating power. Other information that may be included are aGiveBackFlag bit, an object position field, a capability mismatch bit, aUSB Communications capable bit, and a no USB suspend bit.

In an embodiment, a USB_PD_CONTROL command may be issued by a hostcontroller to request a PDC to perform an action. For example, theUSB_PD_CONTROL command may be indicated by a command code of 0x0A inhexadecimal format and may be about one octet long. The following tablelists some examples of control values:

TABLE 11 List of PDC Control Values Control Value Description 0000b noaction 0001b Issue a GotoMin message to a far-end 0010b Issue aHardReset message to a far-end 0011b Get Plug Status 0101b Disable PD0110b Swap Required 0111b Sink OK 1000b SwitchToBrl 1001bOverridePlugStatus 1010b RequestHigherVoltage 1100b GetCapThe PDC may indicate a PDC control by about 4-bits. For example, acontrol value of zero may indicate no action is requested. A controlvalue of one may request the PDC to send a GotoMin message to a far-endport to reduce current drawing from the V_(BUS) wire. A control value oftwo may request the PDC to send a HardReset message to a far-end port toperform a hard reset. A control value of three may request the PDC toupdate cable connection status, where the PDC may perform cabledetection and send the host controller an alert signal when the plugstatus is ready. The host controller may receive the alert signal,retrieve the alert status by issuing a STATUS_ALERT command and followedby issuing a STATUS_USB_PD command to retrieve more detail informationof the plug status as described herein above.

A control value of five may request the PDC to disable PDfunctionalities and act as a non-PD device. A control value of six mayrequest the PDC to initiate a role swap procedure with the far-end port,for example, from a consumer to a provider or from a provider to aconsumer. A control value of seven may request the PDC to connect aV_(BUS) wire to an internal power rail to allow power sink over theV_(BUS) wire. A control value of eight may request the PDC to disconnectthe V_(BUS) wire from an internal power rail and connect the internalpower rail to a barrel jack. A control value of nine may request the PDCto function as a PD plug even when the inserted plug is not a PD plug,for example, the PDC may assume a 5 ampere (A) capable cable is insertedregardless of the cable detection result. A control value of ten mayrequest the PDC to negotiate a higher voltage, for example, afterreceiving a NegotationUpdate event from the PDC, the host controller mayrequest a higher voltage. A control value of twelve may request the PDCto send a capability message to the far-end port, where the capabilitymessage may be a SourceCapability message or a SinkCapability messagedepending on the role of the PDC.

In an embodiment, a VENDOR_SPECIFIC command may be issued by a hostcontroller to request a PDC to send one or more vendor specific messagesas defined in the USB PD specification to the far-end port. In addition,the host controller may issue the VENDOR_SPECIFIC command to retrieve areceived vendor specific message. For example, the VENDOR_SPECIFICcommand may be indicated by a command code of 0x0B in hexadecimal formatand may be a maximum of about twenty eight octets long.

In an embodiment, a STORE_CONFIGURATION command may be issued by a hostcontroller to request a PDC to store configuration parameters to anon-volatile memory. For example, the STORE_CONFIGURATION command may beindicated by a command code of 0x0C in hexadecimal format and may beabout one octet long. When the PDC has completed storing theconfiguration parameters to the non-volatile memory, the PDC may send analert signal to notify the host controller of aStoreConfigurationComplete event (e.g. if the host controller registeredfor the event).

In an embodiment, a RESET command may be issued by a host controller torequest a PDC to perform a hard reset, which may be substantiallysimilar to a reboot when the PDC experiences a power loss. For example,the RESET command may be indicated by a command code of 0x0D inhexadecimal format and may be about one octet long.

In an embodiment, a DEVICE_ID command may be issued by a host controllerto retrieve a PDC hardware and/or a firmware version. For example, theDEVICE_ID command may be indicated by a command code of 0x0E inhexadecimal format and may be about twenty eight octets long.

In an embodiment, a SPECIFICATION_REVISION command may be issued by ahost controller to retrieve a revision of the USB PD specificationsupported by a PDC. For example, the SPECIFICATION_REVISION command maybe indicated by a command code of 0x0F in hexadecimal format and may beabout one octet long. The host controller may function according to thesupported specification.

In an embodiment, a SOURCE_PDO_BATTERY command may be issued by a hostcontroller to indicate the current, the voltage, and/or the power limitswhen the power supply is a battery supply, which may allow a PDC toconfigure a battery PDO accordingly, where the PDO may be sent in aSourceCapabilities message. For example, the SOURCE_PDO_BATTERY commandmay be indicated by a command code of 0x10 in hexadecimal format and maybe about four octets long. It should be noted that the host controllermay also issue the SOURCE_PDO_BATTERY command to retrieve a previouslyconfigured battery PDO. The host controller may include the maximum andminimum voltage when the host controller is employing a battery supplyas well as the power that the battery supply may provide in thiscommand.

In an embodiment, a CAPABILITIES command may be issued by a hostcontroller to a PDC to retrieve a SourceCapabilities or aSinkCapabilities message received from a far-end device. For example,the CAPABILITIES command may be indicated by a command code of 0x11 inhexadecimal format and may be a maximum of about twenty eight octetslong. As discussed herein above, a host controller may request a PDC tosend a Get_Source_Cap or a Get_Sink_Cap message to a far-end port. Afterthe PDC message receives the requested capability message from thefar-end port, the PDC may send an alert signal to the host controller toindicate a received message. The host controller may then retrieve thereceived capability via the CAPABILITIES command. The retrievedcapability may comprise fields as defined in the USB PD specification(e.g. one or more sink PDOs or source PDOs for fixed, variable, and/orbattery supply). When the PDC fails (e.g. timeout) to get a capabilitymessage from the far-end port, all fields may be zeroes.

In an embodiment, a STATUS_ALERT_MASK command may be issued by a hostcontroller to register for alert events with a PDC or to retrievepreviously configured alert events from the PDC. For example, theSTATUS_ALERT_MASK command may be indicated by a command code of 0x19 inhexadecimal format and may be about two octets long. As discussed hereinabove, a host controller may receive an alert signal from the PDC. Thehost controller may register with the PDC for a set of events that thehost controller is interested by issuing the STATUS_ALERT_MASK command.The alert event mask may comprise the same event types and the bitposition as described in Table 2 herein above. It should be noted theconfiguration of the alert events may be stored in a non-volatile memoryat the PDC, for example, by issuing a STORE_CONFIGURATION command asdescribed herein above. However, the figuration of the alert events mayalso be changed dynamically.

In an embodiment, a NEGOTIATION_INFO command may be issued by a hostcontroller to configure a PDC for negotiation parameters or to retrievepreviously configured negotiation parameters from the PDC. For example,the NEGOTIATION_INFO command may be indicated by a command code of 0x1Ain hexadecimal format and may be about four octets long. It should benoted the negotiation parameters may be stored in a non-volatile memoryat the PDC, for example, by issuing a STORE_CONFIGURATION command asdescribed herein above. However, the negotiation parameters may also bechanged dynamically by applying a re-initialization method similar tomethod 600. The following table lists some examples of negotiationparameters:

TABLE 12 List of Negotiation Parameters Bit Position Description b0USBSuspendSupport b1-b2 ExternallyPowered b3 USBCommCapapble b4HigherCapability b5-6  txPeakPower  b7-b16 MaxCurrentSourcePdo1 b17-b26OpCurrentSinkPdo1  b29 OfferPriorityThe USBSuspendSupport parameter may be about 1-bit long and a value ofone may indicate if the device may support USB suspend operation. TheExternllyPowered parameter may be about 2-bits long and may indicate acurrent power supply may be provided by an external power or an unknownsupply. The USBCommCapable parameter may be about 1-bit long and mayindicate if the device may support USB communication. TheHigherCapability parameter may be about 1-bit long and may indicate ifthe device may be fully functional from a default 5V supply. ThetxPeakPower parameter may be about 2-bits long and may indicate a peakpower when the device is a source. For example, the txPeakPower may beindicated in terms of maximum current (Imax) at a percentage ofoperating current (loc) over some duration of time with a certain dutycycle (e.g. Imax of 130% loc at 50% duty cycle). TheMaxCurrentSourcePdo1 parameter may be about 10-bits long and mayindicate a maximum current the device may offer in a default 5V fixedpower supply PDO when the device is a source. The OpCurrentSinkPdo1parameter may be about 10-bits long and may indicate an operatingcurrent the device may sink in a default 5V fixed power supply PDO. TheOfferPriority parameter may be about 1-bit long and may indicate if ahigher current contract may be given priority over a higher voltagecontract.

A host controller may configure a PDC with voltage, current, and/orpower limits for various types of power supplies (e.g. fixed, variable,battery) when a device is a sink or a source. The host controller mayissue a SOURCE_PDO_FIXED_PDO_VAR command to configure a PDC for fixedsource and/or variable source PDOs and may be indicated. For example,the SOURCE_PDO_FIXED_PDO_VAR command may be indicated by a command codeof 0x1B in hexadecimal format and may be a maximum of twenty four octetslong (e.g. up to six PDOs). A fixed supply source PDO may comprise adual-role field, an externally powered field, a USB communicationcapable field, a peak current field, and a nominal voltage file asdefined in the USB PD specification. A variable supply source PDO maycomprise a maximum voltage field, a minimum voltage field, and a maximumcurrent field as defined in the USB PD specification. The hostcontroller may issue a SINK_PDO_FIXED command to configure a PDC for afixed sink PDO. The fixed supply sink PDO may comprise a dual-rolefield, a higher capability field, an externally powered field, a USBcommunication capable field, a nominal voltage field, and an operationalcurrent field as defined in the USB PD specification. For example, theSINK_PDO_FIXED command may be indicated by a command code of 0x1C inhexadecimal format and may be about four octets long. The hostcontroller may issue a SINK_PDO_VAR command to configure a PDC for avariable sink PDO. A variable supply sink PDO may comprise a maximumvoltage field, a minimum voltage field, and an operational current fieldas defined in the USB PD specification. For example, the SINK_PDO_VARcommand may be indicated by a command code of 0x1D in hexadecimal formatand may be about four octets long. The host controller may issue aSINK_PDO_BATTERY command to configure a PDC for a battery sink PDO. Abattery supply source PDO may comprise a maximum voltage field, aminimum voltage field, and an operational current field as defined inthe USB PD specification. For example, the SINK_PDO_BATTERY command maybe indicated by a command code of 0x1E in hexadecimal format and may beabout four octets long. In addition, the host controller may retrieveany of the PDOs by issuing a same command with a read transaction type.It should be noted that the various types of PDOs may be configured orretrieved via other command variations and may not be limited to theabove description. In addition, the PDOs may be stored in a non-volatilememory at the PDC, for example, by issuing a STORE_CONFIGURATION commandas described herein above.

In an embodiment, an INITIALIZATION command may be issued by a hostcontroller to configure a PDC for initialization parameters or toretrieve previously configured initialization parameters from the PDC.For example, the INITIALIZATION command may be indicated by a commandcode of 0x21 in hexadecimal format and may be about four octets long. Itshould be noted the initialization parameters may be stored in anon-volatile memory at the PDC, for example, by issuing aSTORE_CONFIGURATION command as described herein above.

The following table lists some examples of the initializationparameters:

TABLE 13 List of Initialization Parameters Bit Position Descriptionb0-b2 ReceptacleType b3-b4 CurrentRating b5 ProcessSwapToSource b6ProcessSwapToSink b7 InitiateSwapToSource b8 InitiateSwapToSink  b9-b11AcceptBistRequests  b12 AcceptVoltageFromNonPD b13-b14 SMBusTimeoutb15-b16 DeviceRole b17-b19 Source_PDO_Count  b20 Battery_PDO_Count

The ReceptacleType parameter may be about 2-bits long and may indicatethe receptacle or cable types supported by the device. The followingtable lists some examples of receptacle types:

TABLE 14 List of Receptacle Types Type Value Description 000b Captivecable 001b Standard A (with an insert pin) 010b Standard A (without aninsert pin) 011b Micro AB 100b Standard B 101b Micro BThe ReceptacalType parameter may be indicated by about 3-bits. A typevalue of zero may indicate a device with a captive cable. A type valueof one may indicate a standard A cable with an insert pin that indicatesthe presence of a plug. A type value of two may indicate a standard Acable without an insert pin. A type value of three may indicate a microAB cable. A type value of four may indicate a standard B cable. A typevalue of five may indicate a micro B cable.

The CurrentRating parameter may be indicated by about 2-bits and mayindicate the amount of current (e.g. 2 A, 3 A, 4 A, or 5 A) that may benegotiated on the receptacle. The ProcessSwapToSource parameter may beindicated by about 1-bit, where a value of one may indicate the PDC mayautomatically process a far-end request to swap to a source and a valueof zero may indicate the PDC to defer the decision to the hostcontroller. The ProcessSwapToSink parameter may be indicated by about1-bit, where a value of one may indicate the PDC may automaticallyprocess a far-end request to swap to a sink and a value of zero mayindicate the PDC to defer the decision to the host controller. TheInitiateSwapToSource parameter may be indicated by about 1-bit, where avalue of one may indicate the PDC may automatically initiate a swap to asource when possible and a value of zero may indicate the PDC may waitfor the host controller to initiate. The InitiateSwapToSink parametermay be indicated by about 1-bit, where a value of one may indicate thePDC may automatically initiate a swap to a sink when possible and avalue of zero may indicate the PDC may wait for the host controller toinitiate. The AcceptBISTorCarrierReq parameter may be indicated by about1-bit, where a value of one may indicate the PDC may automatically entera BIST eye patter or BIST carrier mode and a value of zero may indicatethe PDC may reject the request. The AcceptBISTtransmit parameter may beindicated by about 1-bit, where a value of one may indicate the PDC mayautomatically enter a BIST transmit mode and a value of zero mayindicate the PDC may reject the request. The AcceptBISTreceive parametermay be indicated by about 1-bit, where a value of one may indicate thePDC may automatically enter a BIST receive mode and a value of zero mayindicate the PDC may reject the request. The AcceptVoltageFromNonPDparameter may be indicated by about 1-bit, where a value of one mayindicate the PDC may connect the V_(BUS) to an internal rail when avoltage is supplied by a non-PD far-end device and a value of zero mayindicate otherwise. The SMBusTimeout parameter may be indicated by about2-bits and may indicate the amount of time (e.g. 0, 11, 100, or 1000millisecond (ms), the PDC may wait after a last SMBus activity beforeentering sleep mode. The DeviceRole parameter may be indicated by about2-bits and may indicate if the device is a consumer, a producer, a C/P,or a C/P. The Source_Pdo_count may be indicated by about 3-bits and mayindicate the number of PDOs to send in a SourceCapabilityMessage. Itshould be noted that there may be at least one PDO. TheBattery_Pdo_count may be indicated by about 1-bit, where a value of onemay indicate the PDC may send a battery PDO and a value of zero mayindicate otherwise.

In an embodiment, a LOW_POWER command may be issued by a host controllerto configure a PDC for low power mode parameters or retrieve previouslyconfigured low power mode parameters from the PDC. For example, theLOW_POWER command may be indicated by a command code of 0x22 inhexadecimal format and may be about two octets long. It should be notedthe low power mode parameters may be stored in a non-volatile memory atthe PDC, for example, by issuing a STORE_CONFIGURATION command asdescribed herein above. However, the lower power mode parameters mayalso be changed dynamically by applying a re-initialization methodsimilar to method 600. The following table lists some examples of lowpower mode parameters, which may all be about 1-bit long:

TABLE 15 List of Low Power Mode Parameters Bit Position Description b0UseSleepMode b1 GoToDisabledState b2 RunSinkCapabilityTimer b3WakeForSMBusStatus b4 WakeOnlyForPD b5 DrawFromVbus b6ImplementDeadBattery b7 UseLongSleepTimer b8 StopSourcingThe UseSleepMode parameter may indicate if the PDC may enter sleep modewhen possible. The GoToDisabledState may indicate if the PDC may enter adisabled state as defined in the USB PD specification. TheRunSinkCapabilityTimer may indicate if the PDC may run aSinkCapabilityTimer during discovery in a sink role, where theSinkCapabiltiyTimer may be as defined in the USB PD specification. TheWakeForSMBusStatus may indicate if the PDC may wake from sleep mode whenSMBus traffic is present. The WakeOnlyForPD parameter may indicate ifthe PDC may wake from sleep mode when a PD cable is inserted, but notwhen a legacy cable is inserted. The DrawFromVbus parameter may indicateif the PDC may draw power from the V_(BUS) wire when possible or onlydraw power from the V_(BUS) wire when the V_(BUS) wire is the onlysource. The ImplementDeadBattery parameter may indicate if the PDC mayreact to a dead battery probing by a far-end device. TheUseLongSleepTimer parameter may indicate if the PDC may use enter a longsleep mode in between polling for cable-type or dead-battery detection.The StopSourcing parameter may indicate if the PDC may stop sourcingvoltage on the V_(BUS) wire. For example, the PDC may cancel a presentcontract when the PDC is a source and may not negotiate for a newcontract as a source. When no contract is in place and the device is aP/C, the device may appear as if it has a dead-battery to a C/Pconnected at the far-end port.

The above discussion is meant to be illustrative of the principles andvarious embodiments of the present invention. Numerous variations andmodifications will become apparent to those skilled in the art once theabove disclosure is fully appreciated. It is intended that the followingclaims be interpreted to embrace all such variations and modifications.

What is claimed is:
 1. An apparatus, comprising: a system management busconfigured to communicate with a Universal Serial Bus (USB) PowerDelivery Controller (PDC); and a processor coupled to the systemmanagement bus and configured to: send a power delivery configuration tothe PDC, wherein the power delivery configuration comprises voltage andcurrent settings; and receive a power delivery status from the PDC,wherein the power delivery status comprises a power capability of a USBport partner.
 2. The apparatus of claim 1, wherein the voltage and thecurrent settings are voltage and current consumption requirements. 3.The apparatus of claim 1, wherein the voltage and the current settingsare voltage and current provisioning capabilities.
 4. The apparatus ofclaim 1, wherein the power delivery configuration further comprises apower delivery role configuration, and wherein the power delivery roleconfiguration comprises a power consumer role, a power provider role, apower consumer/provider (C/P) role, or a power provider/consumer (P/C)role.
 5. The apparatus of claim 1, wherein the power deliveryconfiguration further comprises a USB receptacle type, a USB receptaclecurrent rating, an automatic power delivery role swap mode, an automaticpower delivery role swap initiation mode, a Built in Self-Test (BIST)mode, or combinations thereof.
 6. The apparatus of claim 1, wherein inthe power delivery configuration further comprises power deliverynegotiation parameters, and wherein the power delivery negotiationparameters comprise a USB suspend capability, a USB communicationcapability, a higher power requirement, or combinations thereof.
 7. Theapparatus of claim 1, wherein the processor is further configured tosend a power delivery command to the PDC, and wherein the power deliverycommand instructs the PDC to: request the power delivery capability ofthe USB port partner; stop performing power delivery operations;disconnect from a first power source; connect to a second power source;perform a cable-type detection; perform the power delivery operationsirrespective of a result returned from the cable-type defection, orcombinations thereof.
 8. The apparatus of claim 7, wherein the powerdelivery command further instructs the PDC to: negotiate for an increasein voltage supply with the USB port partner; request the USB portpartner to draw a minimum current, or combinations thereof.
 9. Theapparatus of claim 7, wherein the power delivery command furthercomprises a role swap command, and wherein the role swap commandinstructs the PDC to: initiate a role swap process with the USB portpartner; stop performing power provider operations; start performingpower consumer operations; stop performing the power consumeroperations; and start performing the power provider operations.
 10. Theapparatus of claim 1, wherein the processor is further configured to:send an event configuration to the PDC to register for a notification ofan event, wherein the event comprises a hard reset event, an excessivevoltage drop event, a power delivery negotiation update event, a messagereceived event, or combinations thereof; and receive an eventnotification from the PDC when the event occurs.
 11. The apparatus ofclaim 10, wherein the apparatus further comprises a sub-system busconfigured to communicate with a plurality of sub-systems, wherein themessage received event comprises a request from the USB port partner todraw a minimum current, and wherein the processor is further configuredto instruct the sub-systems to draw less current.
 12. An apparatus,comprising: a power bus interface configured to communicate with auniversal serial bus (USB) port partner; a system management businterface configured to communicate with a host; and a processor coupledto the power bus interface and the system management bus interface,wherein the processor is configured to: receive, via the systemmanagement bus interface, a power delivery configuration from the host,wherein the power delivery configuration comprises voltage and currentsettings; generate a power capability message based on the powerdelivery configuration; and send, via the power bus interface, the powercapability message to the USB port partner.
 13. The apparatus of claim12, wherein the apparatus further comprises a non-volatile memory, andwherein the processor is further configured to: receive, via the systemmanagement bus interface, a power delivery configuration store commandfrom the host; and store the power delivery configuration to thenon-volatile memory in response to the power delivery configurationstore command.
 14. The apparatus of claim 12, wherein the processor isfurther configured to: receive, via the power management bus interface,a power delivery message from the USB port partner, wherein the powerdelivery message comprises a power capability of the USB port partner;and send, via the system management bus interface, the power deliverymessage to the host.
 15. The apparatus of claim 12, wherein theprocessor is further configured to: receive, via the system managementbus interface, a notification request of a power delivery status,wherein the notification request comprises a USB plug detectionnotification request; and send, via the system management bus interface,the power delivery status to the host, wherein the power delivery statuscomprises a USB plug detection status.
 16. The apparatus of claim 12,wherein the apparatus comprises a power switch interface coupled to aplurality of power switches, and wherein the processor is furtherconfigured to: receive, via the system management bus interface, a powerdelivery command from the host, wherein the power delivery commandcomprises a power delivery command; disable a first power switch of theplurality of power switches in response to the power delivery command;and enable a second power switch of the plurality of power switches inresponse to the power delivery command.
 17. The apparatus of claim 16,wherein the power delivery command further comprises a role swapcommand, wherein the processor is further configured to initiate a roleswap process with the USB port partner according to the role swapcommand, and wherein the role swap process comprises a power provider topower consumer role swap process or a power consumer to power providerrole swap process.
 18. The apparatus of claim 12, wherein the processoris further configured to: enter a low power mode, wherein the low powermode is at least lower than a normal operational mode; wake up from thelow power mode; and send, via the system management interface bus, awake up status, to the host after waking up from the low power mode. 19.A method for interfacing with a Universal Serial Bus (USB) PowerDelivery controller (PDC) via a system management bus, wherein themethod comprises: sending a power delivery configuration to the PDC,wherein the power delivery configuration comprises voltage and currentsettings; sending a power delivery command to the PDC, wherein the powerdelivery command instructs the PDC to send a first power deliverymessage to a USB port partner of the PDC; sending a power delivery eventconfiguration to the PDC; receiving a power delivery event from the PDC;and receiving a second power delivery message of the USB port partnerfrom the PDC, wherein the second power delivery message comprises apower capability of the USB port partner.
 20. The method of claim 19,wherein the first power delivery message comprises a hard reset request,wherein the power delivery status comprises a hard reset statusindicating an occurrence of the hard reset event at the PDC, and whereinthe power delivery command further comprises: a first role swap commandthat instructs the PDC to swap role from a power provider to a powerconsumer; and a second role swap command that instructs the PDC to swaprole from the power provider to the power consumer.